寫在前面

這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。

CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

今天想談的 Evidence Management（證據管理），也不是 CRA 規定企業一定要建立一套叫做「CRA Evidence Management System」的制度，而是當我開始思考 Technical Documentation（技術文件）、Conformity Assessment（符合性評估），以及 CRA 未來如何長期維運時，越來越覺得這是一件值得提早處理的事情。

「我們有做啊！」——但 Evidence 在哪裡？

Day 25 談到，我自己越來越不希望企業面對每一套 Regulation，都重新建立一套新的制度，而是希望利用既有的 Risk Management、SSDLC、PSIRT、Supplier Security 等 Cybersecurity Capability，去支援不同的 Compliance Requirement。

但 Capability 建立之後，很快就會碰到下一個問題：

我們怎麼證明這些 Capability，真的在某一個 Product 上執行過？

例如有人問：「這個 Product 有做 Security Testing 嗎？」

回答通常很快：「有啊。」

接著再問：「Test Report 在哪裡？」

這時大家開始找，可能在 Engineer 的電腦裡、Teams 附件裡、SharePoint、Jira、Git Repository，或者 Test Lab 的系統裡。

好不容易找到 Security Test Report，再問一句：

「這份 Report 對應的是哪一個 Product Version？」

事情可能又變得沒那麼簡單。

也是做到這裡，我開始覺得 CRA 有一個很容易被低估的挑戰：不只是 Security Activity 有沒有做，而是 Evidence 能不能跟正確的 Product、Version 與 Requirement 對得起來。

一、Technical Documentation 不是最後才「寫」出來的文件

CRA 會涉及 Cybersecurity Risk Assessment、Annex I Essential Cybersecurity Requirements、Vulnerability Handling、Technical Documentation，以及後續的 Conformity Assessment。

因此很多事情不能只停留在「我們應該有做」，而是必須進一步回答：

我們怎麼知道有做？做的是哪一個 Product？又留下了什麼 Evidence？

所以我現在看 Technical Documentation，已經不太把它想成專案最後才開始準備的一份文件。

它背後其實需要一整串 Product Security Evidence 支撐，例如 Product Description、Architecture、Cybersecurity Risk Assessment、Threat Model、Security Requirements、SBOM、SAST / SCA Result、Security Test、Penetration Test、Vulnerability Handling Records、Standards Mapping，以及 Supplier / Third-party Component Evidence。

換句話說：

Technical Documentation 不是憑空另外寫出來的一份 CRA 文件，而是把 Product Lifecycle 中原本就應該存在的 Security Evidence，有系統地串起來。

如果到了 CRA 專案最後才開始「補 Technical Documentation」，很可能才發現前面的 Evidence 雖然做過，卻沒有按照 Product 或 Product Version 留下來。

二、真正麻煩的，通常不是 Evidence 完全不存在，而是散在不同地方

這其實是大型企業很常見的情況。

Risk Assessment 可能在 SharePoint，Threat Model 在 Confluence，Source Code 在 Git，SAST / SCA Result 在 Security Tool，SBOM 在 Build Pipeline，Test Report 在 QA System，Vulnerability Case 在 PSIRT Platform，Supplier Evidence 在 Procurement System，而 Product Release Information 又放在 PLM。

每一個 Team 都有自己的 System，其實很正常。

所以我並不認為 CRA 一定要把所有 Evidence 複製到同一個 Folder。真正重要的反而是：

這些 Evidence 能不能串得起來？

當我拿到某一個 Product Version 時，我能不能知道它的 Risk Assessment 在哪裡、SBOM 是哪一版、Security Test 用的是哪一份、當時有哪些已知 Vulnerability，以及最後哪些 Evidence 支撐了 Conformity 的判斷？

如果可以，我們才真正具備了 Traceability（可追溯性）。

三、我現在很喜歡用「Evidence Chain」來理解 CRA

假設今天看到 CRA Annex I 的某一項 Requirement，我會希望可以一路往下追：

CRA Requirement → Product Risk → Security Requirement → Design / Control → Implementation → Verification / Test → Evidence → Product Version

如果這條 Chain 可以追，我會比較有信心說，我們不是只有在 Checklist 上打了一個 Yes，而是真的能夠說明：

為什麼這項 Requirement 適用？識別了什麼 Risk？採取了什麼 Security Control？最後又如何驗證這個 Control 確實有效？

舉一個簡單的例子。

假設某個 Product 有 Authentication Function，在 Cybersecurity Risk Assessment 中識別出 Unauthorized Access Risk，因此建立對應的 Security Requirement。R&D 接著實作 Authentication Control，QA / Security 再針對這項 Control 進行 Verification / Testing，最後留下 Test Result。

整條關係就變成：

Risk → Security Requirement → Control → Test → Result

未來如果有人問：「為什麼你認為這項 Security Requirement 已經被處理？」

回答就不只是「因為 Checklist 上寫 Yes」，而是可以一路找到當初識別了什麼 Risk、為什麼採用這個 Control，以及最後怎麼驗證。

對我而言，這才是 Evidence 真正開始產生價值的地方。

四、Evidence Chain 裡最容易被忽略的，其實是 Version

這是我自己越做越覺得重要的一點。

假設 Product V1.0 做過 Penetration Test，但到了 V1.5 新增 Network Interface，V2.0 又更換了一個 Third-party Component。

那麼 V1.0 的 Penetration Test，還能不能直接拿來支撐 V2.0？

我自己不會直接假設可以。

因為 Product 已經改變，Attack Surface 可能改變，Component 也可能不同。所以 Evidence 不能只問「有沒有」，還必須問：

「它對應哪一個 Product Version？」

SBOM 就是很容易理解的例子。

假設 Product V1.0 使用 Library A 2.1，V1.1 升級到 2.3，到了 V2.0 又加入 Library B。這時如果只告訴我「我們有 SBOM」，其實資訊並不足夠。

我真正想知道的是：

這份 SBOM 對應哪一個 Product Release？

因為未來如果發現某個 CVE 影響 Library A 2.1，我們真正需要回答的是：哪些 Product Version 使用了這個 Component？哪些 Customer Product 可能受到影響？

所以：

Product Version ↔ SBOM Version ↔ Component Version

這三者如果可以清楚串起來，SBOM 才不只是 Compliance Artifact，而是真的可以支援 Vulnerability Analysis。

五、不只是 SBOM，Risk Assessment 其實也有 Version

Product 一直改變，Risk 當然也可能跟著改變。

例如新增 Bluetooth，Attack Surface 可能改變；增加 Cloud Connection，Threat Scenario 可能不同；更換 Supplier Component，Supply Chain Risk 也可能重新出現。

所以 Product Cybersecurity Risk Assessment 不應該只是 Product Development 初期做一次，然後永遠不動。

我自己會比較希望 Product Change 發生時，可以 Trigger 適當的 Security Impact Review，再判斷 Risk Assessment、Threat Model、Security Testing、SBOM 與 Technical Documentation 是否需要同步更新。

也就是：

Product Change → Security Impact Assessment → Risk / Requirement / Control Review → Testing / SBOM Update → Technical Documentation / Evidence Update

這也是為什麼我越來越覺得，Evidence Management 跟 Change Management 其實是連在一起的。

Day 17 我們談過 Substantial Modification。現在回頭看，即使先不討論一項 Change 最後是否構成 CRA 定義下的 Substantial Modification，企業內部至少還是需要有能力回答：

Product 到底改了什麼？這個 Change 對原本的 Cybersecurity Evidence 有沒有影響？

否則 Technical Documentation 很可能在幾次 Product Release 之後，就慢慢跟真正的 Product 脫節。

六、所以我現在反而不太想只建立一個「CRA Folder」

第一直覺可能是建立一個 CRA Folder，把 Risk Assessment、SBOM、Test Report、Technical Documentation 全部放進去。

第一年可能很整齊。

但 Product 不斷 Release 之後，很快可能就會看到：

Risk Assessment_Final.xlsx
Risk Assessment_Final2.xlsx
Risk Assessment_ReallyFinal.xlsx

最後大家開始問：「到底哪一份才是正式版本？」

所以我現在比較喜歡另一個概念：

System of Record（正式紀錄來源）。

不一定把所有 Evidence 搬到同一個地方，而是先定義哪一個 System 裡的哪一筆 Record，才是正式 Evidence。

例如 Source Code 的 System of Record 可以是 Git Repository，Product Configuration 可能是 PLM，Issue / Change Record 可能在 Jira，SBOM 有自己的 Repository，Security Finding 在 Security Platform，而 Supplier Evidence 則保留在 Supplier Management System。

CRA Technical Documentation 或 Evidence Index 不一定需要複製所有原始資料，而是應該能夠告訴我們：

正式 Evidence 在哪裡，以及要怎麼找到它。

這樣比較有機會長期維護，也比較不容易產生兩套、三套內容不一致的 Evidence。

七、真正值得管理的，可能不只是 File，而是 Metadata

但 Evidence Index 也不能只是貼一堆 URL。

URL 會改、Permission 會變、System 可能 Migration，甚至很多年後原本使用的 Tool 都不存在了。

所以如果是我自己設計 Evidence Index，我至少會希望記錄 Evidence ID、Evidence Type、Product、Product Version、對應的 CRA Requirement、Owner、System of Record、Record / Document ID、Evidence Version、Review / Approval Status，以及建立或更新日期。

這不是 CRA 規定的格式，而是我自己從長期維運角度會特別在意的資訊。

因為很多年後真正困難的通常不是 Storage Space 夠不夠，而是：

我們還找不找得到？找到了以後，還看不看得懂？

想像十年後，原本的 Engineer 已經離職，Organization 重組過，Jira 或 PLM 換過幾代，Supplier 可能已經不存在，Product 也早已 EOL。

這時即使一份叫做 Security_Test_Final_2027.pdf 的 File 還存在，如果不知道它是哪一個 Product、哪一個 Version、為什麼執行這項 Test、支援哪一項 Requirement，以及當時的 Result 是什麼，那這份 File 的價值其實已經大幅降低。

所以我現在越來越覺得：

Evidence Metadata 可能跟 Evidence File 本身一樣重要。

因為 Metadata 保存的是 Context，而沒有 Context 的 Evidence，很多年後可能只剩下一個不知道用途的 File。

八、Evidence 不會自己更新，所以一定要有 Owner

例如 SBOM Owner 可能是 Engineering，Risk Assessment 可能由 Product Security / R&D 維護，Security Test Evidence 可能由 QA / Security 負責，Supplier Evidence 在 Procurement，而 Vulnerability Case Record 則由 PSIRT 管理。

實際角色當然會依企業組織與 Product Development Model 不同而調整，但有一件事情我覺得不能模糊：

Evidence 必須有人負責。

因為如果沒有 Owner，Evidence Repository 很容易從「知識庫」慢慢變成「資料墳場」。

大家都可以放東西，但沒有人確認它是不是最新版本，也沒有人知道 Product Change 發生後哪些 Evidence 應該一起更新。

除了 Owner，我也會在意 Evidence Quality。

Evidence 不是「有一個檔案就算」。例如 Screenshot 當然可能是一種 Evidence，但如果看不出 Product、Version、Date、Test Condition 與 Result，幾年後可能很難知道它到底證明了什麼。

所以從實務管理角度，我會希望 Evidence 至少具備幾個特性：

Identifiable、Traceable、Version-controlled、Reviewable、Retrievable。

這些不是 CRA 正式規定的 Evidence Criteria，而是我自己認為比較有利於長期管理的基本特性。

九、Evidence Management 也應該被放進 CRA Operational Readiness

Day 22 談 Readiness 時，我提到不應該只看「文件完成幾 %」，而是要確認 Capability 能不能真的跑起來。

到了 Day 26，我自己會再增加一個問題：

「Evidence 找不找得到，而且找出來的是不是正確版本？」

因為 Product Security Process 有執行是一回事，能不能在合理時間內還原當時的 Product Security Decision，又是另一回事。

如果未來 Product 的 Conformity Assessment Route 涉及 Third-party Assessment，一條整理清楚的 Evidence Chain 也會讓溝通容易很多。

例如問到 Requirement X，可以一路找到：

Requirement X → Risk RA-023 → Security Control SEC-018 → Test Case TC-104 → Test Result PASS → Product Version 3.2

這種 Traceability 對我而言，不只是為了 Auditor 或 Conformity Assessment Body。

它其實代表：

公司自己知道 Product Security 是怎麼被建立、驗證與維持的。

十、如果是我，我甚至會做一次「Evidence Drill」

Day 22 我們談過 Article 14 Drill。如果做到 Evidence Management，我可能還會增加另一種很簡單的 Exercise。

隨機抽一個 Product，例如 Product X、Version 3.2，然後開始問：

CRA Applicability / Classification 在哪裡？Risk Assessment 是哪一版？SBOM 在哪裡？Security Test Evidence 在哪裡？目前有哪些 Open Vulnerability？Support Period 怎麼記錄？Technical Documentation 在哪裡？

接著給團隊一個合理時間，看看能不能把整條 Evidence Chain 找出來。

這種演練其實不需要很複雜，但可能很快就會暴露很多平常看「文件完成率」看不出來的問題：

Evidence 根本不存在；Evidence 存在，但找不到；找得到，但 Version 不對；Version 對了，卻不知道支援哪個 Requirement；全部都找到了，最後卻發現已經沒有人知道 Owner 是誰。

我覺得這些問題，才是真正值得在 CRA 正式全面適用以前提早發現的 Gap。

十一、Evidence Management 不只是為了 Audit

這是我最後很想強調的一點。

如果 Evidence 管理得好，真正受益的其實不只是 Auditor 或 Compliance Team。

新的 Engineer 接手 Product 時，可以快速理解 Security Design 與過去的 Risk Decision；PSIRT 發現 Vulnerability 時，可以快速找到受影響的 Component 與 Product Version；Product Change 發生時，可以知道哪些 Risk、Test 與 Documentation 需要重新檢視。

甚至 Management 在看 Product Readiness 時，也不只是看到一個「Green」，而是知道：

Green 背後到底有什麼 Evidence 支撐。

所以我現在開始覺得，CRA Compliance Evidence 如果管理得好，本身也可能逐漸變成 Product Security Knowledge Base（產品資安知識庫）。

這可能才是 Evidence Management 長期真正有價值的地方。

Day 26 小結｜「我們有做」跟「我們證明得出來」，其實是兩件事

做到 Day 26，我自己越來越覺得，CRA 比較成熟的狀態不是 Folder 裡有很多文件，而是這條 Chain 能不能被追蹤：

Product → Requirement → Risk → Control → Test → Evidence → Version

Product Change 發生之後，Risk、SBOM、Testing 與 Technical Documentation 也能跟著適當更新。

很多年後，即使原本參與 Product Development 的人已經不在，公司仍然有能力回答：當初為什麼這樣設計？評估過什麼 Risk？採取了什麼 Control？怎麼 Verification？Evidence 在哪裡？又對應哪一個 Product Version？

做到這裡，Technical Documentation 對我而言才不只是「為了 CRA 準備的一份文件」，而比較像是：

Product Cybersecurity Lifecycle（產品資安生命週期）的可追溯紀錄。

所以如果現在問我 CRA Evidence Management 最重要的是什麼，我可能不會先回答「建立一個 Repository」。

我反而會回答：

建立 Traceability。

Repository 解決的是「東西放在哪裡」，Traceability 解決的則是：

「這份東西到底證明了什麼？又是證明哪一個 Product Version？」

我覺得後者才是 Evidence 真正開始產生價值的地方。

以上仍然只是我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。本文提到的 Evidence Index、System of Record、Evidence Chain 與 Evidence Drill，都只是我自己思考 CRA 導入與長期維運時可能採用的管理方式，並不是 CRA 規定企業必須建立特定形式的 Evidence Management System。

Day 27 預告｜制度、流程、Evidence 都有了，怎麼知道真的經得起檢驗？

做到現在，我們已經一路談過 Governance、Product Classification、Risk Assessment、SSDLC、SBOM、PSIRT、Supplier Security、Technical Documentation、Conformity Assessment，現在又把 Evidence Chain 串了起來。

接下來我反而很想做一件自己比較熟悉的事情：

Audit。

但這次不是 Audit ISO 27001 的 ISMS，而是隨機挑一個 EU Product，從頭開始問：為什麼它在 CRA Scope？Classification 怎麼判斷？Risk Assessment 在哪裡？Annex I Requirement 怎麼處理？SBOM 對不對得上這個 Version？Security Testing Evidence 在哪裡？Vulnerability Handling 跑不跑得起來？Technical Documentation 能不能串起來？Conformity Assessment Route 又是怎麼決定的？

也就是：

不要只 Audit 文件，而是 Audit 一個 Product 的 CRA Lifecycle。

Day 27，我們就從我自己比較熟悉的 Audit 思維出發，來聊：

End-to-End CRA Mock Audit（端到端 CRA 模擬稽核）——如果今天隨機抽一個 Product，我們到底能不能從 Applicability 一路 Trace 到 Product Release 與 Post-market？

我自己覺得，這可能會是 CRA 正式全面適用前，非常值得做的一次「體檢」。